home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-mhsds-supmapping-03.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
11KB
|
414 lines
Network Working S.E. Kille
Group ISODE Consortium
INTERNET-DRAFT July 1993
Expires: January 1994
Use of the Directory to support mapping between X.400 and RFC 822
Addresses
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a ``working
draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Abstract
This document defines how to use directory to support the mapping
between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
1 RFC 1327 Mappings
It is important to be able to represent RFC 1327 mappings in the
directory [2]. The three RFC 1327 mappings are represented within the
O/R Address and Domain hierarchies within the DIT [1, 3].
The benefits of using the existing O/R address and domain trees are:
o It is the ``natural'' location, and will also help to ensure
correct administrative authority for a mapping definition.
o The tree will usually be accessed for routing, and so it will be
efficient for addresses which are being routed.
An alternative approach which is not taken is to locate the
information in separate subtrees, as defined in [3]. By
representing the information in separate subtrees, the mapping
information would be kept in a clearly defined area which can
be widely replicated in an efficient manner. This is not
done, as the benefits of the approach proposed are greater.
The values of the table mapping are defined by use of two new object
classes, as specified in Figure 1.
2 Mapping from X.400 to RFC 822
As an example, consider the mapping from the O/R Address:
PRMD=UK.AC; ADMD=Gold 400; C=GB
This would be keyed by the directory entry:
PRMD=UK.AC, ADMD=Gold 400, C=GB
and return the mapping from the associatedDomain attribute, which
gives the domain which this O/R address maps to. This attribute is
used to define authoritative mappings, which are placed in the open
community tree. The manager of an RFC 1327 mapping should make the
appropriate entry.
Kille Expires: January 1994 Page 1
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
_______________________________________________________________________
rFC822ToX400Mapping OBJECT-CLASS
SUBCLASS OF domain-component
MAY CONTAIN {
associatedORAddress,
nonAuthoritativeAssociatedORAddress,
associatedX400Gateway}
::= oc-rfc822-to-x400-mapping
x400ToRFC822Mapping OBJECT-CLASS
SUBCLASS OF or-address-component 10
MAY CONTAIN {
associatedDomain,
nonAuthoritativeAssociatedDomain}
::= oc-x400-to-rfc822-mapping
associatedORAddress ATTRIBUTE
SUBTYPE OF mhs-or-addresses
SINGLE VALUE
::= at-associated-or-address 20
nonAuthoritativeAssociatedORAddress ATTRIBUTE
SUBTYPE OF associatedORAddress
SINGLE VALUE
::= at-non-authoritative-associated-or-address
associatedX400Gateway ATTRIBUTE
SUBTYPE OF mhs-or-addresses
MUTI VALUE
::= at-associated-x400-gateway 30
nonAuthoritativeAssociatedDomain ATTRIBUTE
SUBTYPE OF associatedDomain
SINGLE VALUE
::= at-non-authoritative-associated-domain
___________Figure_1:__Object_Classes_for_RFC_1327_mappings_____________
Kille Expires: January 1994 Page 2
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
To improve efficiency, the same information is made available in other
places. There are two cases:
1. Representation of mapping information in routing trees other than
the open community tree.
2. Representing a hierarchically derived mapping. For example, a
mapping could be stored in the entry:
MHS-O=Salford, PRMD=UK.AC, ADMD=Gold 400, C=GB
This information could be derived from information in the entry:
PRMD=UK.AC, ADMD=Gold 400, C=GB
However, it would take an extra lookup to find this information.
This information is stored by use of the
nonAuthoritativeAssociatedDomain attributes. For example, the entry
MHS-O=UCL, PRMD=UK.AC, ADMD=Gold 400, C=GB
could have a nonAuthoritativeAssociatedDomain attribute of value
``UCL.AC.UK''. It is the responsibility of the manager of the entry to
track changes in authoritative mappings, and to ensure that all such
registed mappings are up to date.
Functionally, mapping takes place exactly according to RFC 1327. The
longest match is found by the following algorithm.
1. Take the O/R Address, and derive a directory name. This will be
the O/R Address as far as the lowest OU.
2. Look up the entire name derived from the RFC 1327 key in a the
open routing tree. The open tree must be used, to ensure
authoritative information.
3. Check for associatedDomain or nonAuthoritativeAssociatedDomain
attributes.
o If the mapped value is present, stop.
Kille Expires: January 1994 Page 3
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
o If not, strip one component of the name, and repeat.
If the non-authoritative information is provided, the mapping can
always be achieved with two lookups.
Because of the availability of aliases, some of the table mappings may
be simplified. In addition, the directory can support mapping from
addresses using the numeric country codes.
3 Mapping from RFC 822 to X.400
There is an analogous structure for mappings in the reverse direction.
The domain hierarchy is represented in the DIT according to RFC 1279.
The domain:
AC.UK
Is represented in the DIT as:
DomainComponent=AC, DomainComponent=UK, O=Internet
This has associated with it the attribute associatedORAddress, with a
value:
PRMD=UK.AC; ADMD=Gold 400; C=GB
There is an optimisation analogous to the reverse mapping provided by
the nonAuthoritativeORAddress attribute.
The ``table 3'' mapping defined in RFC 1327[2] is provided by the
associatedX400Gateway attribute. This value may be different in
different routing trees, as this is not a globally unique mapping. It
is also possible to identify multiple possible associated gateways.
This information is looked up at the same time as mapped O/R
addresses. In effect, this provides a fallback mapping, which is
found if there is no equivalence mapping. Functionally, mapping takes
place exactly according to RFC 1327. The longest match is found by
the following algorithm.
Kille Expires: January 1994 Page 4
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
1. Derive a directory name from the domain part of the RFC 822
address.
2. Look up this name in the open routing tree to find the mapped
value (associatedORAddress or nonAuthoritativeAssociatedORAddress
or associatedX400Gateway.). There should never be an attributes
of more than one of these types present.
o If one of the three mapped value types listed above is
present, stop.
o If not, strip one component of the name, and repeat.
If associatedORAddress or nonAuthoritativeAssociatedORAddress is
found, this will define the mapped O/R Address. If the
non-authoritative information is provided, the mapping can always be
achieved with two lookups. If an associatedX400Gateway is present,
the address in question will be encoded as a domain defined attribute,
relative to the O/R Address defined by this attribute. If multiple
associatedX400Gateway attributes are found, the MTA may select the one
it chooses to use.
Because of the availability of aliases, some of the table mappings may
be simplified. In addition, the directory can support mapping from
addresses using the numeric country codes.
References
[1] S.E. Kille. X.500 and domains. Request for Comments RFC 1279,
Department of Computer Science, University College London,
November 1991.
[2] S.E. Kille. Mapping between X.400(1988) / ISO 10021 and RFC 822.
Request for Comments 1327, Department of Computer Science,
University College London, May 1992.
[3] S.E. Kille. Representing the O/R Address hierarchy in the
directory information tree, April 1992. Internet Draft.
Kille Expires: January 1994 Page 5
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
4 Security Considerations
Security considerations are not discussed in this INTERNET--DRAFT .
5 Author's Address
Steve Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
England
Phone: +44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille, ISODE Consortium, GB
Kille Expires: January 1994 Page 6
INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 July 1993
A Object Identifier Assignment
_______________________________________________________________________
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (7)}
mapping OBJECT IDENTIFIER ::= {mhs-ds 4}
oc OBJECT IDENTIFIER ::= {mapping 1}
at OBJECT IDENTIFIER ::= {mapping 2}
oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1} 10
oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2}
at-associated-or-address OBJECT IDENTIFIER ::= {at 1}
at-non-authoritatative-associated-or-address OBJECT IDENTIFIER ::= {at 2}
at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3}
at-non-authoritative-associated-domain OBJECT IDENTIFIER ::= {at 5}
_______________Figure_2:__Object_Identifier_Assignment_________________
Kille Expires: January 1994 Page 7